Many existing data processing systems require multiple copies of control information and data so that recovery from a failing system or reconfiguration of a system may be provided. The ability to have a duplexed copy of information is known to be achieved through hardware and software services. Significant difficulties are encountered in maintaining duplexed copies of data, however.
Specifically, performance is disadvantageously impacted if the duplexed copies are recorded one after the other. If the duplexed copies are recorded concurrently, significant complexity is created in assuring at least one correct copy exists and in synchronizing the overlap of operations to minimize the performance degradation.
Further, duplexed copies provide an exact replica onto media. Should a logical error occur in the requests which place data on the data store, that logical error is propagated to both copies of the data. A further disadvantage of duplexed data occurs in those environments where an exact second copy is not required. For instance, in those systems in which information is recreated from logs or journals of prior activity, a duplexed copy of control information and data is not needed.
In many instances, to have a duplexed copy of control information and data would be disadvantageous as it would increase the quantity of storage required, significantly increase the management of data information, and greatly increase the complexity either or both, the hardware and software supporting the duplexed operations. These complexities may fail to provide the availability improvement anticipated by the duplexing capability in as much as the complexity associated with establishing, maintaining and switching to a duplexed copy are often error prone and difficult to test for correct operation.
A second technique in which more than one copy of control information and data is maintained is found in existing systems which support versioning of the information. Through versioning, multiple occurrences of control information and data may exist at different levels of currency. It is typical in such systems for a copy of the control information and data to be taken at established points in time. Such copies may be complete copies of all of the relevant control information and data or may be increment copies of portions of the relevant data store.
In order to recover from a failure of the control information and data store, a previous version is typically restored and incremental changes are applied from journals or logs. This requires that each user of the data store maintain a journal or a log of changes made following creation of a version. This requirement is extremely expensive, both from a performance and product development cost perspective. The performance disadvantage comes from requiring that any recoverable change in the data store be recorded on the log or journal prior to completing the unit of work requesting the change. Complexity and costs occur in developing the log or journal code to support a wide variety of workloads, with widely varying arrival rates and execution path lengths.
A versioning approach does not provide the flexibility to support recovery coordination and dynamically access two instances of the data store concurrently to achieve the necessary recovery operation.
Based on the foregoing, a need exists for a technique for providing a structure that is not an exact duplication of a related structure but can be used effectively for recovery from system failure or planned reconfiguration. A further need exists for a method and system for providing a rebuilt structure which does not degrade system performance or add to the complexity of the system. A further need exists for a technique that will synchronize the two instances of the structure, which are not identical and which do not require the maintenance and use of a recovery log.